NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/226

Text File | 1996-08-06 | 4.1 KB | 107 lines

Path: engnews1.Eng.Sun.COM!taumet!clamage
From: [e-mail] (James Kanze US/ESC 60/3/141 #40763)
Newsgroups: comp.std.c++
Subject: Re: (no subject)
Date: 31 Jan 1996 16:34:17 GMT
Organization: SEL
Sender: [e-mail]
Approved: [e-mail] (comp.std.c++)
Message-ID: <[e-mail]>
References: <4elfbq$[e-mail]>
NNTP-Posting-Host: taumet.eng.sun.com
Content-Type: text
In-Reply-To: "john's message of 30 Jan 1996 09:51:25 PST
Apparently-To: [e-mail]
Content-Length: 3412
X-Lines: 83
Originator: clamage@taumet

In article <4elfbq$[e-mail]> "john (j.d.) hickin"
<[e-mail]> writes:

|> Some current compilers allocate memory for heap objects from inside
|> the constructor code.  This isn't great when exceptions can be thrown
|> and indeed generated code from compilers that support exception handling
|> seems to abandon the idea.

|> Does the standard say anything about how memory should be allocated?

Yes and no.  The defined semantics of the new operator are that the
memory is allocated, then the constructor is called.  However, the
compiler can do anything it wants, as long as the `observable
behavior' is the same.  Since the physical function call is not part
of the observable behavior, the implementation is perfectly free to
generate the call to new in the constructor itself, a la cfront, if it
so desires.  (And I don't really see where this would cause problems
with exception handling.)

|> My question is motivated by the following simple program which exhibits
|> different behavior when exception handling is enabled compared to when
|> it isn't.  Would such behavior be accptable inder the provisions of the
|> standard?

As far as the standard is concerned, exception handling is always
enabled.  From a quality of implementation point of view, I wouldn't
think very highly of a compiler which changed the semantics of new
when exception handling was disabled.

|> // -----------------------------------------------------------------

|> #include <stddef.h>

|> struct Y
|> {
|>   Y() {}
|>   void* allocate() { return 0; }
|> };

|> struct X
|> {
|>    X() {}
|>    void* operator new( size_t ) { return (void*)42; }
|>    void* operator new( size_t , Y& alloc ) { return alloc.allocate(); }
|>    void  operator delete( void* ) {}
|>    //void operator delete( size_t , Y& ); // not yet supported by my compiler
|> };


|> #include <iostream.h>

|> main()
|> {
|>   Y y;
|>   X* ptr = new(y) X;
|>   cout << "ptr == " << (int)ptr << "\n";
|> }

|> The output is 0 when exception handling is enabled and 42 when it isn't.

The output is 0 when a C++ compiler is used.  It may be anything when
a compiler for another language is used, but the above is a conforming
C++ program, whose observable behavior is to output 0.  Exception
handling has nothing to do with the questions.  (Of course, if you
disable exception handling, you have told your compiler not to compile
C++, but a very similar, slightly smaller language.  Since this
language is defined by the compiler vendor, he could argue that the
above output corresponds to his definition of the language.  See my
comments above on quality of implementation.)

(In the above discussion, I'm ignoring the fact that conversion
between int and pointer is implementation defined.  Strictly speaking,
the implementor may define that converting a null pointer to an int
yeilds 42 when exception handling is disabled, and 0 when it isn't.
Somehow, I doubt that this is actually what is happening; modifying
the operator new so that the write a static variable, or output a
message, according to which one was called, should clear this up.)
--
James Kanze         Tel.: [phone]        email: [e-mail]
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
                -- A la recherche d'une activitΘ dans une region francophone


[ comp.std.c++ is moderated.  Submission address: [e-mail].
  Contact address: [e-mail].  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]